1. Field of the Invention
This invention relates to software delivery and more particularly relates to software delivery of a developmental software library in a developmental phase for a mainframe computer.
2. Description of the Related Art
In developing applications for mainframe operating systems, there is a need to release software to Independent Software Vendors (“ISV”) during a developmental phase so they can work in parallel with the application design team to develop software tools for the application. Updates of the release software should be frequent to capture changes and defect corrections made by the software design team and to respond to defects hindering development of ISV tools. Typically, as shown in the flowchart 100 of FIG. 1, when an application is developed and tested such that the application can be sent to the ISVs, the application code is used to create 102 a software driver that can be sent to the ISVs. A software driver typically consists of development software libraries. Typical elements of the software libraries are source code, object code, modules, panels, macros, and sample code.
Next, the software driver is tested 104. Typically, the testing includes regression testing using test cases. For example, testing for International Business Machine's (“IBM”) Information Management System (“IMS”), a database and transaction management application, may include approximately one-hundred and fifty test cases. In addition, testing may include verification of installation and sample systems. An example of such a testing method is the IMS Installation Verification Program (“IVP”), which includes a set of panels to guide a user through customization and testing of sample IMS systems.
If a defect is detected 106 during testing, the defect is reported 108, corrected 110, a new software driver is created 102, and the driver is tested 104 again. The testing 104 after a defect is corrected 110 may be extensive or minimal depending upon the defect.
Once the above mentioned testing 104 is completed, the software driver is converted 112 to a proprietary format for a software maintenance application such as System Modification Program Extended (“SMP/E”) that is typically integrated with the z/OS or OS 390 mainframe operating systems. In order to ensure that the conversion 112 did not introduce errors, the converted software is tested 114 again. If errors are detected 116, they are again reported 108, corrected 110, and a new software driver is created 102. The driver may have to be retested 104 and reconverted 112 and the conversion retested 114 many times. Once this conversion testing 114 is completed, the SMP/E compatible software driver is typically loaded 118 onto tapes and delivered 120 to the ISVs. SMP/E support libraries are also included with the SMP/E compatible software driver.
Once the ISVs receive the tapes, they in turn install 122 the SMP/E compatible driver on their mainframe computers, and if the software driver is not a software driver update, the ISV may then use 124 the software driver. Traditionally, the same method 100 is repeated in order to create 102 software driver updates. Typically, a software driver update includes just the changed files or libraries of a software driver. If a software driver update is created 102 and converted 112 to the SMP/E format, typically only incremental updates are included and bundled together in the software driver update, each incremental update relates to a particular change in the software application. Incremental updates may depend on each other depending on the kinds of changes that have been made.
The process of converting 112 a software driver update to the SMP/E format and testing 114 may be very cumbersome for the software driver design team, especially if there are a large number of incremental updates in a software driver. For example, rather than meeting a goal of monthly updates, the IMS design team may only be able to deliver one software driver update to the ISVs in a six month development period. This creates a problem since the ISVs are not able to receive timely updates and errors are not corrected quickly. ISVs may have to work with a software driver having uncorrected defects for an extended period of time which may delay completion of software driver tools developed by the ISVs.
The process of installing 122 an SMP/E compatible driver update is cumbersome for the ISVs because the SMP/E tool installs 122 the driver update incrementally. When an ISV applies the driver update, there may be a large number of incremental updates included and some of the incremental updates may require manual involvement. The manual involvement during installation 122 of a driver update may be cumbersome and repetitive when a large amount of incremental updates are included in the driver update. Once the software driver update is installed 122 and manual involvement is finished, the software driver update may be used 124.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method for efficient software delivery. Beneficially, such an apparatus, system, and method would reduce the time and effort required from the software driver design team and from the software driver users, such as ISVs, to install an update of a software driver that replaces essentially the whole software driver code, would be responsive to the needs of ISVs for quick error correction, and would allow software driver updates with a large number of incremental updates to be packaged in a single code update.